Community

Very sadly I score a 1. I really must get out more :-)

Couldn't agree more Steve on all your points, but then that is hardly surprising from a fellow Standards geek :-)

Bob,

I know it sounds very traditional, but good old fashioned Business Analysis, tied to a sound vision of what the organization wants to achieve in the way of improved services/SLAs, differentiation against competitors, cost reduction and increased bottom line, is the basic answer. Once you have decided on those things then the Business Analyst, provided you have one or more with the requisite broad knowledge of the standards and delivery landscape, should be able to provide recommendations on the most appropriate way forward. As I said it is good old fashioned gap analysis driven from business requirements/desires. I really don't think corporate planning should be dictated by the standards that are out there or the networks that can transport or validate them.

In the end as my previous post stated, one of the advantages from a selfish point of view is that if there isn't an ISO 20022 compliant message out there that fits your purpose you can always create your own message or variant of one that exists and still claim to be supporting the standard (which technically you are)!

The key to this approach is having an appropriate environment that enables this choice of appropriate data structure per function and delivery channel. There may be differences in real time vs non time critical, totally secure vs secure as it needs to be; adoption of a global standard vs leveraging extensions to create commercial differentiation. Whatever you do don't let your internal infrastructure limit your choices. You might say "of course she would say that" but just because I work for a vendor that has particular interest in this area doesn't necessarily mean that it isn't so. :-)

As Bob and Gary know I am somewhat pedantic so I should point out that not all ISO 20022 messages are SWIFT MX or indeed vice versa. Other organizations other than SWIFT have submitted messages which are not represented in the MX message set. Also the version and variant numbers often differ between messages present in both. Just to confuse things SWIFT also have Solutions such as Clearing, Funds, etc that also sometimes have ISO 20022 compliant messages which are neither published as an ISO 20022 standard nor are the present in the SWIFT UHB MX specifications. 

So as at Q1 this year there were two hundred and something messages published on ISO 20022 website but over 500 different messages and or schema versions/variants published between ISO 20022, SWIFT MX and SWIFT Solutions. For those of you with insomnia I can provide you with the detailed comparison spreadsheet if you contact me!

As a message standard it is becoming anything but; a victim of its own built in extensibility. But then we often forget that ISO 20022 is a methodology and data dictionary; for an actual message to be compliant they don't even have to be XML structures. So perhaps the issue of over which network messages get transmitted and in SWIFT's case validated in certain services, is less of an issue than it would seem if there isn't agreement on the standards themselves.

I have had some experience of this over the past couple of decades and seen it work sometimes for periods of time although almost inevitably they have had a finite lifespan. Most occur when two companies have overlapping or closely abutting functional products or services. Think of it in terms of a Venn diagram. Both parties are often competing with larger entities that perhaps cover that whole space so working together allows them to compete. 

However; businesses, especially publically owned ones are driven by shareholder returns and market expectations. So inevitably the spotlight will fall on that intersection and the functional horizon beyond and be seen as fertile ground for future development of product or services. That's when the relationship crumbles. Trust is a key to keeping that relationship for as long as possible but people move on and sometimes the trust exits the building with them.

So it as well as keeping your enemies closer it is also a case of "Making hay whilst the sun shines". As long as you don't rely on the revenues from the relationship to stay afloat then why not leverage relationships of that nature. Just don't enter in to it believing the marriage is made in heaven and "till death do us part"!

Speaking personally, I believe Barry makes some valid points, which probably won't surprise many as I have voiced similar concerns both to other SWIFT partners and to SWIFT employees many times over the past few years.

I do also admit that the situation is not quite as straight forward as comparing SWIFT to FPL FIX and ISDA FpML. SWIFT is different in that it is not only a standards body like those two others but also provides a highly secure and resilient infrastructure for the transmission of its standards. SWIFT in its guise as an ISO RA also bears some additional costs and responsibilities. As such it would be not only unreasonable but also unfeasible for it to exactly fit with the models that FIX and FpML are promoted and maintained by.

I have also like many, been and will continue to be an advocate of financial institutions using SWIFT standards where they are the obvious choice within the transaction lifecycle. Let's face it a substantial part of my career has been built on promoting exactly that; the last 23 out of the past 25 years in this business to be exact.

I have also over the past decade become more involved with the FpML and FIX world and I agree with Barry that SWIFT could learn much from those organisations in the standards domain. Both standards are open and the specifications are free to use and now are the defacto standards within their asset classes and functional domains. They have also achieved this without recourse to major infrastructure, instead leveraging of the expertise that exists within their membership. As Barry states they enhance that adoption by supplying free to use tools that in some ways would be analagous to the SWIFT SDK which is a commercial product.

I believe that the root issue is that, as has been pointed out, there are the two contradictory objectives, the creation/maintenance/promotion of the standards and the requirement to fund the overall operation of the network and business. I certainly have no issue with SWIFT being commercial and I can see a very good reason for trying to drive commercial software and services revenues that could potentially at some point in the future significantly cover the costs of running the network, effectively making it free to use for it's members. That makes a lot of sense but it does then mean that that same drive to be commercial and cover costs leaks to the standards operation. 

Personally, I would like to see SWIFT revert to the type of structure that it had when I first started dealing with it in the late '80s. You had SWIFT that you spoke to on standards issues, SWIFT Terminal Services (STS) that was the overtly commercial arm, selling interface devices like the ST200 and ST400 and then there was SWIFT Network Services (SNS) that ran the network. Back then you knew what the drivers where in each part of the business. Access to standards was with one piece and accreditation to connect to the interface devices with another. In this structure I can see that it is much easier to maintain an altruistic albeit cash neutral position for standards maintained mostly through membership and voluntary participation and an application and services business that can largely fund the network.

What we increasingly have is the commercial drive overriding what should be impartiality with respect to the standards and their implementation. As has already been said, the annual partner conference has over the past few years been a room full of SWIFT advocates from software, service and bureau providers waiting to be told which part of their dinner SWIFT were planning to eat next whilst wrapping this up in a delivery which suggested we should all welcome this and that it represented an opportunity for us! As I said earlier in my comment I do not have an issue per se with SWIFT trying to compete with thier partners what I object to is being told that we should welcome it or see it as a level playing field.

I attended a SWIFT open day a few months ago which was attended by both partners such as the one that I work for and also by member banks. Ostensibly each presentation was "market" lead in that it was a presentation on what was going on in Funds or Corporate to Bank Payments and obviously these have a pretty straightforward correlation to the underlying FIN and ISO 20022 message categories. So far so good, all perfectly reasonable and educational. My issue was that each presentation I went to was ended with either a blatent pitch for a SWIFT product such as Integrator or a pitch for SWIFT consultancy services. To the extent that they had wheeled in clients of both to give member backing to those products and services to their peers in the audience. Outside these sessions there were rolling demos of products throughout the afternoon. 

Once again I reiterate that I have no problem with this from a commercial perspective, I would run the open day the same way if I could. My issue is that in no way can that be deemed a level playing field as we don't get a chance to pitch our alternative solutions which we should do as SWIFT partners. Wouldn't it be so much easier if when you turned up to a SWIFT open or partner event you knew you were going to a standards oriented event or if you were going to a SWIFT Inc event you were going to hear product and service related info. 

SWIFT have already launched the Arkelis brand seperately as a SWIFT Company, why not go the whole hog and put the other products and services under the same banner. We can then all decide if we want to have relationships at the standards level, prodct/services or both. Arkelis can then decide where it wants to spend it's profits, subsidising the network for example. Nice and simple, everything out in the open.

And as a result SWIFT standards could perhaps start to leverage the approaches that have made FIX and FpML dominant in their space without recourse to charging for every tool that might enhance the adoption of the standard.

As stated at the top these are my personal views and should not necessarily be assumed to be that of my employer.